home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 6 / CU Amiga Magazine's Super CD-ROM 06 (1996)(EMAP Images)(GB)(Track 1 of 4)[!][issue 1997-01].iso / cucd / online / fidonetts / fsc-0065.001 < prev    next >
Text File  |  1992-08-02  |  20KB  |  599 lines
  1. Document: FSC-0065
  2. Version:  001
  3. Date:     02-Aug-1992
  4.  
  5.  
  6.  
  7.  
  8.                           Type 3 ASCII:  A proposal
  9.                           =========================
  10.  
  11.                                  Mark Kimes
  12.                               FidoNet 1:380/16           
  13.  
  14.  
  15.  
  16.  
  17. Status of this document:
  18.  
  19.      This FSC suggests a proposed protocol for the FidoNet(r) community,
  20.      and requests discussion and suggestions for improvements.
  21.      Distribution of this document is unlimited.
  22.  
  23.      Fido and FidoNet are registered marks of Tom Jennings and Fido
  24.      Software.
  25.  
  26.  
  27.  
  28.  
  29. Introduction:
  30. ============
  31.  
  32. This document describes a type of mail packet called type 3 ASCII.  Type
  33. 3 ASCII was designed with how Fidonet Technology Networks (FTNs) handle
  34. mail (netmail, echomail, groupmail) in mind.  It was also designed to
  35. allow new distribution methods to be introduced.  For instance, it is
  36. possible to combine the best of echomail and groupmail methods using
  37. type 3 ASCII packets.  Finally, type 3 ASCII provides reliability, space
  38. and speed advantages over the current mail packet type 2 (see "Type 3
  39. ASCII vs. Type 2" section below).
  40.  
  41.  
  42.  
  43. Packet structure:
  44. ================
  45.  
  46. (See "Definitions" section below for the meaning of any arcane symbols)
  47.  
  48. Type 3 ASCII packets and archived bundles will ride existing transport
  49. services (mailers) as attached files.  Type 2 mail and type 3 ASCII mail
  50. can both be sent to a node without conflicts.  Naturally, the receiving
  51. node should be able to process type 3 ASCII mail before it is sent.
  52.  
  53. Type 3 ASCII packets are named <fileroot><.><3KT> when sent to a remote
  54. site. Archives containing type 3 packets are named <fileroot><.><3?A>
  55. when sent to remote sites.  How these files are stored or named locally
  56. is not within the scope of this document.
  57.  
  58. A type 3 ASCII packet consists of a packet header, followed by a
  59. carriage return, followed by zero or more messages, followed by a NUL.
  60. A type 3 ASCII message consists of a message header, followed by a
  61. carriage return, followed by zero or more characters of message text,
  62. followed by a NUL.
  63.  
  64. Diagramatically speaking,
  65.  
  66.         (Text in brackets [] indicates optional data)
  67.  
  68.   Type 3 ASCII packet:      header
  69.                             <cr>
  70.                             [messagehdr1
  71.                              <cr>
  72.                              [text]
  73.                              NUL
  74.                              messagehdr2
  75.                              <cr>
  76.                              [text]
  77.                              NUL
  78.                              ...
  79.                              messagehdrn
  80.                              <cr>
  81.                              [text]
  82.                              NUL
  83.                             ]
  84.                             NUL
  85.  
  86.  
  87. Breakdown:
  88. =========
  89.  
  90.         (See "Description of Fields" section below for information on
  91.          individual fields.)
  92.  
  93.   Packet header:
  94.   =============
  95.  
  96.     <3ASCII><cr>
  97.     From<cr>
  98.     [To]<cr>
  99.     Creator<cr>
  100.     [Password]<cr>
  101.     [Area]<cr>
  102.     [Tag1<sp>data1<cr>]
  103.     [Tag2[<sp>data2]<cr>]
  104.     ...
  105.     [Tagn[<sp>datan]<cr>]
  106.  
  107.   Message header:
  108.   ==============
  109.  
  110.     From<cr>
  111.     [To]<cr>
  112.     [Subject]<cr>
  113.     Date<cr>
  114.     [Area]<cr>
  115.     ID<cr>
  116.     [Ref]<cr>
  117.     [Tag1<sp>data1<cr>]
  118.     [Tag2[<sp>data2]<cr>]
  119.     ...
  120.     [Tagn[<sp>datan]<cr>]
  121.  
  122.  
  123.   Message body:
  124.   ============
  125.  
  126.     Free-flowing, NUL-terminated text.  May be composed of any combination
  127.     of ASCII characters > 31 (from the space character, ASCII character
  128.     32, onward) and may include <cr> as a "paragraph terminator."  Systems
  129.     which display message text should wrap long lines to suit their
  130.     application.
  131.  
  132.     To be in compliance with this document, implementations must be able
  133.     to forward messages with at least 131,072 (128K) characters of text
  134.     (including the terminating NUL).  Network politics may outlaw
  135.     messages of lesser size, but that is beyond the scope of this
  136.     document.  If a compliant implementation encounters a message longer
  137.     than the 128K limit, it may truncate the message text before
  138.     forwarding.  However, since it is easy to support messages of a
  139.     length limited only by available disk space, it is encouraged that
  140.     you do so and not impose artificial restrictions.  The purpose of
  141.     this limit is to guarantee a minimum size that will be passed, _not_
  142.     to restrict implementations to the "minimum."
  143.  
  144.     Line feeds (ASCII character 10) are reserved and should not normally
  145.     appear in message text.  Future plans call for their use as "escape
  146.     codes."  So called "soft carriage returns" (ASCII character 141)
  147.     should not be contained in transmitted message text unless the actual
  148.     character itself is desired.
  149.  
  150.     Tabs (ASCII character 9) should not be used in message text as their
  151.     use often leads to unreadable messages.  How many spaces should be
  152.     used at a remote site to represent them?
  153.  
  154.  
  155.  
  156.  
  157. Description of Fields:
  158. =====================
  159.  
  160.   Note:  the maximum length of any field line (excluding, of course,
  161.          message text) is 255 characters including the terminating <cr>.
  162.          In practice, a bit of restraint should be practiced to keep
  163.          fields as small as possible.  The maximum length of any header
  164.          is 32767 bytes, including terminating <cr>.  In practice, this
  165.          limit should never be approached.
  166.  
  167.   Date:
  168.   ====
  169.  
  170.     YYYYMMDDhhmmss<optional time zone>
  171.  
  172.     where
  173.       YYYY = year with century, as in 1991 or 2001
  174.       MM   = month, as in 01 to 12
  175.       DD   = day of month, as in 01 or 28
  176.       hh   = hour of day, as in 00 to 23
  177.       mm   = minute of hour, as in 00 to 59
  178.       ss   = second of minute, as in 00 to 59
  179.       <optional time zone> = offset from GMT in 15 min. increments
  180.                              (i.e. "+4" (sans quotes) for GMT + one
  181.                              hour)
  182.  
  183.     All numbers are represented in decimal.
  184.  
  185.     Samples:  19990419143200
  186.                 (April 19, 1999 at 2:32:00 pm)
  187.               19921223020303+8
  188.                 (December 23, 1922 at 02:03:03 GMT + 2 hours)
  189.  
  190.     The Date field is required.
  191.  
  192.  
  193.   From and To:
  194.   ===========
  195.  
  196.     The From field contains the writer's name followed by a valid FTN
  197.     network address. For the purposes of this document and current
  198.     implementations of type 3 ASCII packets, the format of a valid FTN
  199.     network address is:
  200.  
  201.       Domain<#>Zone<:>Net</>Node[<.>Point]
  202.  
  203.       where
  204.  
  205.         Domain is a text string from 1 to 8 characters in length
  206.         containing only alphabetical [A-Za-z] and/or numerical [0-9]
  207.         characters.
  208.  
  209.         Zone is a decimal number from 1 to 65533.
  210.  
  211.         Net is a decimal number from 1 to 65533.
  212.  
  213.         Node is a decimal number from 0 to 65533.
  214.  
  215.         Point is a decimal number from 0 to 65535 (may be omitted if 0).
  216.  
  217.       The FTSC or whatever body guards tech specs may change this
  218.       definition in the future as it sees fit.
  219.  
  220.     The full format of a type 3 ASCII From or To field is:
  221.  
  222.     [User Name<@>]Domain<#>Zone<:>Net</>Node[<.>Point]
  223.  
  224.     If User Name<@> is missing, assume user name is Sysop.  User Name
  225.     may be composed of any combination of ASCII characters > 31 (from
  226.     the space character, ASCII character 32, onward) excluding <@>.
  227.  
  228.     If <.>point is missing, assume point 0.
  229.  
  230.     The To field contains the recepient's name and address as above.
  231.     The To field is optional.  If it is missing, message/packet is
  232.     broadcast mail (no definite, single recipient).  In this case there
  233.     must be an area (if the To field is omitted in the packet header,
  234.     there must be an area in the packet header and all messages must be
  235.     broadcast mail for that area.  If omitted in the message header, the
  236.     message or the packet must have an area and message may be displayed
  237.     as being addressed to "All@Anywhere").  A <cr> must still be present
  238.     as a "space holder."  In broadcast mail, it is permissible to give
  239.     only the name of the user (without following address) in a message
  240.     header; however, the name must end with <@> (to distinguish it from
  241.     an address with no User Name).  Note this means a single broadcast
  242.     mail packet can be sent to many nodes.
  243.  
  244.     The From field is required.
  245.  
  246.     In the case of From and To fields in the packet header,
  247.     [user name<@>] is probably unimportant.
  248.  
  249.     In the interests of saving space, domains such as "Fidonet.org"
  250.     should be replaced with just "Fidonet," as the ".org" modifier has
  251.     no meaning to an FTN site.  Domains should be treated case
  252.     insensitively.
  253.  
  254.     Sample:   John Doe@Fidonet#1:380/16
  255.                 (User "John Doe" in domain "Fidonet" zone 1 net 380
  256.                  node 16, implied point 0)
  257.  
  258.  
  259.   Creator:
  260.   =======
  261.  
  262.     Name of the product that produced the packet.  This field is
  263.     required.
  264.  
  265.  
  266.   Password:
  267.   ========
  268.  
  269.     A password to use for security.  This field is optional.  If
  270.     omitted, a <cr> must still be present as a "space holder."  How this
  271.     field is used is implementation-defined.
  272.  
  273.  
  274.   Subject:
  275.   =======
  276.  
  277.     The subject field should contain text hinting at the subject of the
  278.     message text.  It may be composed of any combination of ASCII
  279.     characters > 31 (from the space character, ASCII character 32,
  280.     onward).  The subject field is optional.  If omitted, a <cr> must
  281.     still be present as a "space holder."
  282.  
  283.  
  284.   Area:
  285.   ====
  286.  
  287.     Area fields consist of a string of alphanumeric characters plus
  288.     space, "-" and "_" (ASCII characters 32, 45 and 95 respectively).
  289.     Area fields are optional with the following consequences:
  290.  
  291.       If the area field in a packet header is missing, the messages in
  292.       the packet will have area fields present for broadcast mail,
  293.       omitted for personal mail.
  294.  
  295.       If the area field in a packet header is present, all the messages
  296.       in the packet will be broadcast mail for the area specified in the
  297.       packet header.  The message area fields will not be present.
  298.  
  299.     When an area field is omitted, a <cr> must still be present as a
  300.     "space holder."
  301.  
  302.  
  303.   ID:
  304.   ==
  305.  
  306.     An ID consists of the originating address of the message plus a
  307.     serial number, in the form:
  308.  
  309.       origaddr<sp>serialno
  310.  
  311.      The originating address should be specified in a form that
  312.      constitutes a valid return address for the originating network. If
  313.      the originating address is enclosed in double-quotes,  the entire
  314.      string between the beginning and ending double-quotes is considered
  315.      to be the orginating address.  A double-quote character within a
  316.      quoted address is represented by by two consecutive double-quote
  317.      characters.  The serial number may be any eight character
  318.      hexadecimal number,  as long as it is unique - no two messages from
  319.      a given system may have the same serial number within one year. The
  320.      manner in which this serial number is generated is left to the
  321.      implementor.
  322.  
  323.        Notes:  The "old" format of
  324.                  Zone<:>Net</>Node[<.>Point][<@>Domain]
  325.                for FTN addresses is allowed in this field.
  326.  
  327.                The address portion of the ID may be omitted if it is
  328.                exactly the same as the From address (less User Name<@>).
  329.                In this case, the ID field should begin with a space
  330.                followed immediately by the serial number.
  331.  
  332.                In the case of foreign network addresses, this address
  333.                gives you the "true" origin, and the From address gives
  334.                you the gateway at which the message entered FTN
  335.                territory.  This allows you to gate replies to "foreign"
  336.                sites.
  337.  
  338.  
  339.          Samples:  some.other.net.addr ABCDEF12
  340.                     12345ABC
  341.  
  342.          (Assume From field of second sample contained
  343.           "Joe Blow@Fidonet#1:380/16",so complete constructed ID would be
  344.           Fidonet#1:380/16 12345ABC
  345.           Note address would be copied exactly from the From field.)
  346.  
  347.     The ID field is required.
  348.  
  349.  
  350.   Ref:
  351.   ===
  352.  
  353.     A Ref consists of the ID of the original message to which this message
  354.     refers (usually as a reply).
  355.  
  356.          Sample:   Fidonet#1:380/16 12345ABC
  357.                    (would reference the second ID sample above)
  358.  
  359.     The reference field is optional.  If omitted, a <cr> must still be
  360.     present as a "place holder."
  361.  
  362.                    
  363.   Tag<sp>Data:
  364.   ===========
  365.  
  366.     The tag+data lines are type 3 ASCII's method of automatically
  367.     expanding its headers.  A tag consists of a sequence of uppercase
  368.     alphabetic (A-Z inclusive) and/or numeric sequence of characters and
  369.     possibly a hyphen (ASCII character 45) and/or underline (ASCII
  370.     character 95), up to 12 characters in length (a name).  A tag name
  371.     can be followed optionally by a space (ASCII character 32) and data.
  372.     Data may be composed of any combination of ASCII characters > 31
  373.     (from the space character, ASCII character 32, onward).
  374.  
  375.     To aid in developer experimentation with tags in type 3 ASCII, it is
  376.     guaranteed that the FTSC or whatever body guards tech specs will
  377.     never "canonize" a tag beginning with the two characters "X-" (ASCII
  378.     character 88 followed immediately by ASCII character 45).  Thus,
  379.     tags may use this combination before tag names to guarantee
  380.     uniqueness.
  381.  
  382.     Experimental tags may be stripped by conforming implementations
  383.     during message passthrough.  This helps prevent experimental tags
  384.     from escaping from test sites.
  385.  
  386.       Samples (tag names are invented):
  387.  
  388.         FOLLOW AFILEN.AME
  389.         X-TAG SOMEDATA
  390.         LONETAG
  391.  
  392.     Tag<sp>data fields are optional and may be completely omitted when
  393.     creating a packet.  Exception:  all tag<sp>data fields except,
  394.     possibly, experimental fields, should be passed through with a
  395.     message being forwarded.
  396.  
  397.     Predefined tags:
  398.     ===============
  399.  
  400.     Tag         Where         Data        Meaning
  401.     ---         -----         ----        -------
  402.     PRIV        Msg Hdr       None        Message is private
  403.     FOROK       Pkt Hdr       None        Packet may be forwarded without
  404.                                           unpacking -- all messages are
  405.                                           to the To: address in the packet
  406.                                           header
  407.  
  408.  
  409.  
  410. Type 3 ASCII vs. Type 2:
  411. =======================
  412.  
  413. Type 3 ASCII saves between 6% to 11% in raw packet size over type 2
  414. (using Tiny Seenbys with the type 2 packets to make the test as fair as
  415. possible), depending on how area tags for echos are used in the type 3
  416. ASCII packet (in packet header vs. message headers).  7% smaller would
  417. be the norm for the way we do echomail business now.  The tests
  418. conducted were most unscientific but should be close to everyday
  419. echomail-oriented reality.
  420.  
  421. Compressed packets are a slightly different story.  Type 3 ASCII
  422. compresses the same as type 2 when using area tags for echos in the
  423. message headers.  Type 2 compresses approximately 2.5% better when area
  424. tags are used in the type 3 ASCII packet headers instead.  Either way,
  425. compressed type 3 ASCII packets are smaller than comparable type 2
  426. packets due to the smaller raw packet size.  Even compression ratios
  427. would be the norm for the way we do echomail business now.
  428.  
  429. Type 3 ASCII imports between 2% to 5% faster (depending on algorithms
  430. used).  There is no discernable difference on export.  Keep in mind that
  431. this particular test has too many variables (software, hardware, relative
  432. efficiency of code, etc.) to be considered a real benchmark.  Most of the
  433. speed savings is in not having to process SEEN-BY and PATH lines.  The
  434. lack of end-of-text control information is a real boon.
  435.  
  436. Type 2 has no method for reliably obtaining the full 5-D origin address
  437. of a message.  Type 3 ASCII provides a reliable method of obtaining
  438. full origin address information for both the true origin (in whatever
  439. network) and the gateway which brought the message into FTN territory
  440. (if from a foreign network).  This means that even if a message
  441. originated in a network with which your software has no idea how to
  442. communicate, you can still send a reply to an FTN node for gating.
  443.  
  444. Type 2 has no reliable method for stopping dupes.  Type 3 ASCII has a
  445. mandatory ID field, very similar to type 2's optional MSGID, which can
  446. be used for reliable dupe checking.
  447.  
  448. Type 2 echomail has control information scattered throughout the message
  449. body, including SEEN-BY and PATH information at the end of the message.
  450. This causes problems for developers, who often opt for fixed-length
  451. buffers and arbitrary message length limits.  All control information
  452. for Type 3 ASCII is in the extensible message header.  Moreover, type 3
  453. ASCII has generous set limits to which programmers can work, and which
  454. users can therefore rely on.
  455.  
  456.  
  457.  
  458. Definitions:
  459. ===========
  460.  
  461.   Except where noted otherwise, numbers are in decimal.
  462.  
  463.   Although the ASCII character set is normally defined as being limited
  464.   to characters from 0 to 127, this document acknowledges the existence
  465.   of an eighth bit in most bytes and uses the term (loosely) to mean
  466.   characters from 0-255.  Network politics may or may not "outlaw" the
  467.   use of some of those bytes; that is outside the scope of this document.
  468.  
  469.   Note:  text in brackets [] indicates an optional field.  See
  470.          "Definitions" section below for meaning of text in <>.  See
  471.          "Description of Fields" section below for information on
  472.          individual fields.
  473.  
  474.  
  475.   Alphabetic:
  476.   ==========
  477.  
  478.   A-Z and a-z, ASCII characters 65 to 90 and 97 to 122 inclusive.
  479.  
  480.  
  481.   Numeric:
  482.   =======
  483.  
  484.   0-9, ASCII characters 48 to 57 inclusive.
  485.  
  486.  
  487.   Alphanumeric:
  488.   ============
  489.  
  490.   All characters alphabetic and numeric.
  491.  
  492.  
  493.   Hexadecimal:
  494.   ===========
  495.  
  496.   0-9 and A-F (or a-f), ASCII characters 48 to 57 and 65 to 70 (or 97 to
  497.   102) inclusive.
  498.  
  499.  
  500.   NUL:
  501.   ===
  502.  
  503.     ASCII character 0.
  504.  
  505.  
  506.   <cr>:
  507.   ====
  508.  
  509.     Carriage return, ASCII character 13.
  510.  
  511.   <lf>:
  512.   ====
  513.  
  514.     Line feed, ASCII character 10.
  515.  
  516.   <sp>:
  517.   ====
  518.  
  519.     Space, ASCII character 32.
  520.  
  521.   <@>:
  522.   ===
  523.  
  524.     @, ASCII character 64.
  525.  
  526.  
  527.   <#>:
  528.   ===
  529.  
  530.     #, ASCII character 35.
  531.  
  532.   <:>:
  533.   ===
  534.  
  535.     :, ASCII character 58.
  536.  
  537.   </>:
  538.   ===
  539.  
  540.     /, ASCII character 47.
  541.  
  542.   <.>:
  543.   ===
  544.  
  545.     ., ASCII character 46.
  546.  
  547.  
  548.   <3ASCII>:
  549.   ========
  550.  
  551.     The literal string "3ASCII" (not including quotation marks).  This
  552.     text, followed by a <cr>, identifies a type 3 ASCII packet.
  553.     Implementations should *not* processes a file unless this identifier
  554.     is found on the first line, but should probably log the occurrence.
  555.  
  556.  
  557.   <fileroot>:
  558.   ==========
  559.  
  560.     Eight alphanumeric characters that serve as the "root" of a
  561.     filename.
  562.  
  563.  
  564.   <3KT>:
  565.   =====
  566.  
  567.     The literal string "3KT" (not including quotation marks).
  568.  
  569.  
  570.   <3?A>:
  571.   =====
  572.  
  573.     The literal string "3?A" (not including quotation marks) with the
  574.     question mark (?) being replaced by a decimal integer from 0 to
  575.     9 (ASCII 48 to 57 inclusive).
  576.  
  577.  
  578.  
  579.  
  580. Miscellaneous notes:
  581. ===================
  582.  
  583. jim nutt invented MSGIDs and REPLYids (ref. FTS-0009), which were lifted
  584. very nearly whole to become IDs and Refs in this document.  Tom Jennings
  585. invented Fido and Fidonet <tm and stuff> from whole cloth and RAM chips.
  586. NET_DEV's continual foolishness inspired me to do instead of whine.
  587. Let's see if this cuts down on the whining...
  588.  
  589.  
  590.                                 -end-
  591.  
  592.  
  593.  
  594. Mark Kimes
  595. 1:380/16.0@Fidonet
  596. (318)222-3455 data
  597. 542 Merrick
  598. Shreveport, LA, USA  71104
  599.